1. Field of the Invention
The present invention relates to a clustered femtocell network including a plurality of femtocell access points that are connected via a logical interface to a mobile network in order to provide user equipments with radio access to said mobile network, wherein said mobile network includes a Mobility Management Function—MMF—. Furthermore, the present invention relates to a method for operating such a clustered femtocell network.
2. Description of the Related Art
In the present application reference will be made to various documents containing technical specifications. For the sake of simplicity the documents are referenced as follows:                [1] 3GPP, “TS 36.300 V8.10.0; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2”, September 2009        [2] 3GPP, “TS 23.401 V8.8.0; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”, December 2009        [3] 3GPP, “TS 36.423 V9.0.0; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 Application Protocol (X2AP)”, September 2009        [4] 3GPP, “TS 36.413 V9.0.0; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)”, September 2009        [5] Soliman et al. Hierarchical Mobile IPv6 Mobility Management (HMIPv6). IETF RFC 4140.        [6] WiMAX Forum, “WMF-T32-001-R015v01; WiMAX Forum Network Architecture; Architecture Tenets, Reference Model and Reference Points; Base Specifications”, November 2009        
Femtocell Access Points (FAPs) are essentially small-scale versions of the (macro-cell) Base Stations (BSs) that provide User Equipments (UEs, e.g. mobile phones and Internet tablets) with radio access to a Mobile Network (MN). A distinguishing characteristic of FAPs is that—unlike the BSs—they are installed by the customers of a Mobile Network Operator (MNO) themselves and on their premises in a “plug-and-play” manner. However, although FAPs are deployed by the MNO's customers they are part of the MNO's Radio Access Network (RAN) and thus have similar requirements as the BSs. Specifically, all radio and mobility management related functions are under the control of the MNO and handled in a uniform manner to ensure radio co-existence between FAPs and BSs and also to enable user mobility between them.
To exchange user data and control data (e.g. signaling messages) between FAPs and the Mobile Network, FAPs are connected via a logical interface to the MN similar to the BSs. Physically, however, data from a MNO customer's FAP is sent over the customer's local network, then over the customer's backhaul link to the public Internet, and finally through the public Internet into the MN of the respective operator (and vice-versa). This increases the traffic load in the customer's network and in particular on the backhaul link, which is often a resource bottleneck. Furthermore, signaling messages experience an increased latency compared to the fast connections between BSs and the MN.
In many cases, each of the MNO's customers (e.g. a private household) will deploy only a single FAP. In the case of Clustered Femtocell Networks (CFNs), a large number of FAPs are deployed by an organization with the intention to build a mobile network which benefits from the Femtocell concept (i.e. higher throughput, better coverage, etc.), but at the same time uses proven, widely-used technologies such as 3GPP LTE or mobile WiMAX. A typical example of a Clustered Femtocell Network is an Enterprise Femtocell Network. Here, the Enterprise deploys an internal Femtocell network which is technically still under the control of a mobile network operator.
A CFN is likely deployed for a large number of mobile device users. This means that the rate of intra-FAP handovers of UEs (i.e. from one FAP of a CFN to another FAP of the same CFN), hand-ins (i.e. from the macro-cellular network to the CFN) and hand-outs (i.e. from the CFN to the macro-cellular network) is potentially high. Also, it is likely that a significant amount of voice or data traffic is local to the CFN, e.g. it is exchanged between UEs connected to FAPs of the same CFN.
In current MN architectures, user data between two local UEs would have to be sent via the respective mobility management function (MMF) of these UEs within the MN. It is understood that the general term “mobility management function” refers to the corresponding function within each specific technology, e.g. the SGSN in a 3GPP, the MME/S-GW in a 3GPP LTE [1,2] and the HO and DP Functions in a WiMAX architecture [6]. For the MMF being involved in the entire mobility management, the data needs to traverse the CFN's backhaul link and the public Internet twice: Once when sent from the CFN to the mobility management entity(-ies) in the MN and once on the way back. Similarly, whenever a handover occurs within the CFN, mobility management signaling messages need to be exchanged between the involved FAPs and the mobility management function within the MN.
Localized mobility management for CFNs is currently not foreseen in the MN architecture standards. A straight-forward approach to implementing a localized mobility management would be to take a hierarchical approach (e.g. similar to [5]), in which the mobility anchor point in the MN is responsible for handling mobility between the macro-cellular network and the CFN(s) and in which each CFN would have a subordinate local mobility anchor point for handling local mobility. However, this would require the introduction of a new interface between the mobility anchor points of the MN and CFN levels as well as changes to the implementation of the MN-level mobility anchor, which would have to deal with both BSs, single FAPs and CFN mobility anchors concurrently.
As current MN architectures support a “re-selection” of a UE's mobility anchor point, another approach would be to place a regular mobility anchor point into each CFN. Hand-ins and hand-outs would then be implemented via a re-selection between peer mobility anchor points. The disadvantage of this approach is that the interface between mobility anchor points is not secured, because it is assumed that it is an interface internal to the MNO and not exposed to but the most trusted clients (if at all).
Furthermore, state of the art solutions provide localized mobility management for picocells or UMA (Unlicensed Mobile Access) by locally implementing a complete Radio Access Network that is integrated into the MNO's network. As picocells are completely owned and operated by the MNO, this does not create security issues, but requires a significantly deep integration with the MN and involves a non-negligible overhead for provisioning by the MNO. Consequently, such solutions are offered by the MNO to its largest customers, at the most.
All approaches described above would mean significant changes to the current architecture.